Modern event-driven software applications, such as many client-side web applications, can be hard to write, hard to organize and hard to maintain. The software code for such applications tends to quickly grow out of control as application developers add more functionality and developers to a project. The code for routing and handling events is notoriously difficult to develop and maintain, especially where there are many different types of events and many different actions to be taken in response to events. To make it easier to develop and maintain event routing and handling code of an application, developers often agree on an event routing and handling framework. Unfortunately, current frameworks are inadequate for some software applications, especially for applications where the software codebase undergoes frequent change by multiple developers.
In general, the task of an event routing and handling framework is to route runtime events that occur during execution of the application to actions to be performed in response to the events. For example, an event routing and handling framework may be used to route a “click” event on a particular graphical user interface button to a certain action to be performed when a user clicks on that button.
According to a “direct” event routing and handling framework, events are mapped directly to the actions to be taken. This framework is used in some client-side web applications, for example. There, Uniform Resource Locators (URLs) corresponding to user interface events (e.g., a click of a button) are typically directly mapped to event handlers. When a user interface event occurs, the URL corresponding to the event is used to determine the event handler to invoke. However, the direct event routing and handling framework can result in a brittle and inflexible codebase. For example, if the codebase is modified to generate a new event for which a particular action is to be taken (e.g., a new button is added), then the codebase may need to be additionally modified to map the new event to an event handler. If such mapping is neglected, for example because of developer non-communication, then occurrence of the new event during execution of the application may cause a defect to manifest. Further, since events are directly tied to event handlers through a URL-to-action mapping, seemingly unrelated codebase changes can break the mapping. For example, a developer may change a URL associated with a particular event for cosmetic reasons or some other reason unrelated to event routing and handling thereby causing the particular event to no longer be properly handled when the particular event occurs.
Based on the foregoing, it is clearly desirable to provide a framework for routing events in software applications that avoids the code development issues of direct event routing and handling frameworks.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.